home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 6244 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.5 KB
  1. Path: cs.uwa.edu.au!jasonb
  2. From: jasonb@cs.uwa.edu.au (Jason S Birch)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: MUI 3.2
  5. Date: 16 Feb 96 16:47:38 GMT
  6. Organization: The University of Western Australia
  7. Message-ID: <jasonb.824489258@cs.uwa.edu.au>
  8. References: <jasonb.824024887@cs.uwa.edu.au>  <68771502@0humpty.tomate.tng.oche.de>
  9. NNTP-Posting-Host: decadence.cs.uwa.oz.au
  10. X-Newsreader: NN version 6.5.0 #3 (NOV)
  11.  
  12. humpty@TOMATE.TNG.OCHE.DE (Andreas Mixich) writes:
  13. >So do this for *your* system. NEV:MUI is 277kb on my sys after removing a
  14. >lot of unused progs' preferences. I think ENV is misused too much. For
  15. >every crap setting, that I need one time in two weeks env is used. $TZ,
  16. >$USER, $AUTHOR, $HOME, $HOST, $DOMAIN,LHAOPTS,ENV:SC/ etc. all these BELONG
  17. >TO ENV: !!!
  18.  
  19. >But why a 50kilo ToolManager.prefs ? Why a ForcIcon prefs which is altered
  20. >maximum once a day. Why the icons for CED ? Or the prefs for phonebill,
  21. >which I use once a month or even less ? Why can Nico Francois save the
  22. >ToolsDaemon Prefs in S: without slowing down the whole process ? I change
  23. >this sometimes daily. You even do not notice that it is in S: Yes, at the
  24. >beginning I was searching for the prefs in env:....
  25.  
  26. Surely all this supports my idea for having a slight modification to
  27. the way env-vars work so we don't need to keep a copy in env: *and*
  28. envarc:, as opposed to changing MUI alone? Altering MUI would mean
  29. only MUI programs benefit. If getenv followed multiple assigns, *all*
  30. programs would benefit, including that 50k TM prefs file (which,
  31. incidentally, is nearly as big as my entire env:mui directory).
  32.  
  33. >If you like ENV that much: Okay, lets store TERM prefs and its phonebook
  34. >there, and yes, CEDDEFAULTS belongs there anyway, and perhaps UMS.config
  35. >and the prefs for AmiIRC, AmiTCP (and all belonging tools) and so on and
  36. >on. Yeah, let's expand this idea and let your editor put its auto-bakup in
  37. >env: also so you do not here every 5 minutes your hard disk scratching.
  38.  
  39. env: is for storing your environment. Hence the name. Anything that
  40. constitutes part of your environment should go there (and will make
  41. things much easier if AmigaOS ever goes multiuser). If *only*
  42. preferences that had been changed since the last save and "Use"'d were
  43. stored in env:, it would make this a much nicer solution. After all,
  44. the config files have to be stored *somewhere*.
  45.  
  46. >But, put ENV: into SD0: before or RAD: ;-))
  47.  
  48. Ah, that would be a big mistake. Unlike RAM:, SD0: and RAD: both use
  49. normal filesystems - your 5 byte TZ variable is probably taking up 512
  50. bytes alone on your system.
  51.  
  52. >If I would list my ENV: now it would conatin more than a hundred lines from
  53. >which at least 70 are not needed to be in env. In env only things should be
  54. >like variables, especially when they shall be used from scripts as well or
  55. >other programs. Mini-settings for _very_ time critical programs or so. But
  56. >not for *EVERYTHING*. This was a huge mistake of the Amiga designers not to
  57. >forbid explicitley usage of env: for everything that claims itself to be a
  58. >preferences-file. Okay, there is still the need for a difference between
  59. >USE and SAVE.
  60.  
  61. Only keeping settings that have changed since the last save in env:
  62. solves this problem.
  63.  
  64. >Why not leaving S: for scripts, make a dir SYS:Configs (some programs
  65. >follow this new way already) for saving of prefs or let it be
  66. >Sys:Prefs/Settings/Applications where you could have a drawer named USE and
  67. >one named SAVE.... And for things like window positions for GUI engines,
  68. >such as Triton or MUI, okay, let them use env:
  69.  
  70. The more different places you allow for settings, the more difficult
  71. it becomes to set up a multiuser system.
  72.  
  73. >> and for the system to be patched, just as I prefer OpenLibrary() to be
  74. >> altered so it looks in PROGDIR: as well as LIBS: and the current dir,
  75. >> rather than forcing all programs to look for libraries there
  76. >> themselves.
  77.  
  78. >Yes, but I think ENV: is overused, absolutley overdosed....
  79.  
  80. It wouldn't matter so much if it wasn't all copied into RAM: on each
  81. boot and left there. My idea again: when something looks for a file in
  82. env: that isn't there, the system automatically checks for it in
  83. envarc: as well. It could be implemented simply by adding envarc: to
  84. the env: assign, and making things like getenv work properly.
  85.  
  86. >Ciao, Andreas
  87. >Internet: humpty@tomate.tng.oche.de
  88.  
  89. -- 
  90. Jason S Birch                        ,-_|\ email: jasonb@cs.uwa.edu.au
  91. Department of Computer Science      /     \ Tel (work): +61 9 380 1840
  92. The University of Western Australia *_.-._/ Fax (work): +61 9 380 1089
  93. Nedlands  W. Australia  6907             v  Tel (home): +61 9 386 8630
  94.